Section 6 
BACKUP AND RECOVERY 



In this section: See page 

Introduction - 6-3 

File Backup and Reorganization 6-4 

Saving Files and Directories - 6-5 

Restoring Files anc Directories 6-5 

Power Resumption 6-6 

Implementing the Power Resumption Facility 6-6 

Power Resumption Functions 6-7 

File Recovery ♦• 6-8 

Designating Recoverable Files 6-8 

Recovery File Creation 6-8 

File Recovery Process 6-9 

Taking Cleanpoints 6-9 

Requesting Rollback • ► 6- ID 

Recovering After System Failure 6-10 

File Restoration 6-10 

Designating Restorable Files 6-11 

Journal File Creation 6-11 

File Restoration Process 6-12 

Checkpoint Restart. •. 6-12 

Checkpoint 6-13 

Checkpoint File Assignment 6-13 

Taking a Checkpoint •• 6-14 

Checkpoint Processing * 6-15 

Restart -. 6-16 

Requesting a Restart • 6-17 

Restart Processing 6-18 



C203-02 6-1 



Backup and Recovery 



^unnarv 



This section cescrioes oeckup ana reorganization of disk files, 
tne preservation of the execution environment during a power 
failure, the recovery of files a: the recorc level, the 
restoration of corrupted files, and the recovery and restart, of 
"task grcuos in an absentee processing environment. 
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INTRODUCTION 

The system provides facilities that enable you to backup and 
reorganize disk files, preserve the execution environment during 
a power failure, perform file recovery at the record level, and 
restart a program from a previously established point. 

Backup and The file backup and reorganization facility consists of the save 
Reorganize and restore functions. These functions provide you with a means 
of: 

• Backing up disk files or volumes on 1/2-inch or 1/4-inch 
magnetic tapes, or other mecia, so that a copy of the files 
is available should the original files become corrupted. 

• Consolidating (concatenating) files that have become 
fragmented through continuous updating. 

Power The power resumption facility uses the memory save and auto- 

Resumption restart unit tc preserve the memory image through a power 

failure lasting up to 2 hours. If power is restored during this 
time, the power resumption facility reconnects the previously 
online peripheral and communication devices and restarts the 
tasks that were running when the power failure occurred. If the 
power failure lasts more than 2 hours,- the memory image is 
destroyed and the. power resumption facility disabled. When 
power is restored, you can reinitialize the system and use the 
file recovery and checkpoint facilities to restart the system 
from a p-eviously established restart point. 

File File recovery enables you to dynamically save recorc images 

Recovery before they are uDdated and, 1f necessary, later write the 

image 5 back to the file, thereby returning the file to its 
unaltered state. File recovery provides file integrity 1n the 
event of a system failure. The system supports file recovery 
through three distinct functions: 

• Before-1mage recording - Preserves a record prior to its 
being updatec. 

• Cleanpoint or checkpoint declarations - Issued in your 
program to define a point at which a multirecord or 
multifile update transaction 1s complete. When an update 

transaction is complete, the associated before images are 
destroyed* 

• Rollback, recovery, or restart functions - Returns the files 
to their unaltered state by applying all before images that 
nave been recorded since the last cleanpoint. 
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File File restoration procedures enaole you to reconstruct disk files 

Restoration and/or volumes that are damaged as a result of a device 

failure. File restoration is provided tnrough two distinct 

functions: 

• After-image recording - Preserves a record of the updates 
made to files. 

• Roll Forward utility - Reapplies updates (after images) to 
files to bring therr up to their most recent consistent state 
before the aevice failure. 

After images are used in conjunction with the Save, Restore, and 
Roll Forward utilities to return files to a known state if cata 
in the files is destroyed as a result of a device failure. 

The cleanpoint, rollback, and recovery functions should be usee 
to provide file recovery in a transaction-oriented environment. 
They are best suited for applications in which a single 
transaction causes a number of record updates. In an absentee 
Processing environment, the checkpoint and restart procedures 
should oe used for file recovery and program restart. 

Checkpoint The checkpoint restart facility enables you to establish a point 
Restart in your program to which you can return at a later time and 

continue processing, 'he return point (checkpoint) is used to ' 
save the current status of the task group. You issue a 
checkpoint call in your program when you reach a point in your 
processing at which the orogram could oe restarted. A restart 
can be performed at the most recently completed checkpoint at 
any time during processing. 3f the task group is abnormally 
terminated for any reason, it can be restartea at the most 
recent valid checkpoint. 

RLE BACKUP AND REORGANIZATION 

File backup and reorganization is implemented tnrough the 5ave 
and Restore utilities. The Save utility transfers disk files 
and cirectories to 1/2-inch or l/4-1nch magnetic tape, or to 
another specified storage medium. The Restore utility 
reconstructs- the saved f^les and directories anc outs them back 
on oisk. Any file that has oeen saved and restored is 
automatically reorganized for disk space efficiency. 

Since file access time efficiency may be lessened a'ter a file 
has been ir use for some time, it is recommended that disk 
volumes be periodically saved and restorec. The files on the 
restored volume will be be compacted, resulting in optimal soace 
allocation and imp r ovements in the time required to search 
directories and check access rights. 
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The Save utility enables you to save an entire disk volume, a 
directory and all its subdirectories and files, or a specified 
file. If you are saving a directory, you can specify the number 
o* levels of subdirectories (with their associated files) to be 
saved. Any access control lists associated with the saved files 
and directories are also saved, unless you specify otherwise, 

T he saved data, whether a whole volume, a file, or directories 
and files, is stored in a save file. The save file can be a 
magnetic tape or disk file, or an output device such as a card 
punch. When the Save utility processes the files and 
directories to be saved, it adds information that is meaningful 
only to the Restore utility. The saved files and directories 
are net just copies of the originals. 

The Save utility can be executed while the files being saved are 
in use. Used with a journal file (refer to "File Restoration" 
;ater in this section), this type of save operation provides a 
dynamic and concurrent backup facility for high volume systems 
that cannot af f o *d periodic shutdown to perform static file 
saves. 



Restoring Files and Directories 



You can restore from a save file all or part- of the data you 
saved on that file. You can restore an entire volume (1f you 
saved an entire volume), a directory and its associated 
suboirectcries, or a specified file. Whatever you restore, you 
can return to the place from which you saved it, or you can 
place it 1n another directory or another volume. 

Data saved from one type of disk can be restored to another 
type, provided. the new disk has the required capacity. For 
example, you can restore a diskette volume onto a cartridge disk 
volume, or a partially filled mass storage device volume to a 

cartridge module d : sk volume. 
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Saving Files and Directories 



The Save utility enables you to save an entire disk volu 
directory and all its subdirectories and files, cr a spe 
file. If you are saving a directory, you can specify th 
of levels of subdirectories (with their associated files 
saved. Any access control lists associated with the sav 
and directories are also saved, unless you specify other 

The saved data, whether a whole volume, a file, or direc 
and files, is stored in a save file. The save file can 
magnetic tape or disk file, or an output device such as 
punch. When the Save utility processes the files and 
directories tc be saved, it adds information that is mea 
only to the Restore utility. The saved files and direct 
are not just copies of the originals. 

The Save utility can be executed while the files being s 
in use. Used with a journal file (refer to "File Restor 
later in this section), this type of save operation prov 
dynamic and concurrent backup facility for high volume s 
that cannot afford periodic shutdown to perform static f 
saves. 



Restoring Files and Directories 



You can restore from a save file all or part- of the data 
saved on that file. You can restore an entire volume (i 
saved an entire volume), a directory and its associated 
subdirectories, or a specified file. Whatever you resto 
can return to the place fron which you saved it, or you 
place it in another directory or another volume. 

Data saved from one type of disk can be restored to anot 
type, provided. the new disk has the required capacity. 
example, voj can restore a diskette volume onto a cartri 
volume, or a partially filled mass storage device volume 
cartridge module disk volume. 
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: RESUMPTION 

Power resumption is an optional facility that allows the system 
execution environment to be automatically restarted after a 
power interruption. The central processor must have the memory 
save and autorestart unit. This unit can preserve the memory 
image tnrough a power failure lasting up to 2 hours. (It 
cannot, nowever, preserve the state of the I/O controllers, nor 
can it ensure that no operational changes have been made to the 
mounted volumes.) 

If fewer than 2 hours have elapsed when power is returned to the 
central processor, the power resumption facility will perform 
the following functions: 

• Reinitialize the system software, 

• Reconnect peripheral devices. 

• Reconnect communication devices serviced by the Asynchronous 
Terminal Driver (ATC) line protocol handler or the 
Teleprinter (TTY*) line Drotocol handler. (Refer to the 
System Building and Administration manual and the System 
Programmer's Guide - Volume ! for information about these 
line protocol hanclers;) 

• Restart certain application tasks that were active at :he 
time of the failure. Application tasks that are capaole of 
being restarted are those using the display formatting and 
control facility and those containing user-written code to 
handle power failure and power resumption, 

iting the Power Resumption Facility 

The power resumption facility must be included in tne Executive 
at system building* The central processor must contain a memory 
save and autorestart unit that has been activated by the 
operator (refer to the System User's Guide for activation 
procedures) . 

When oower resumption 1s specified in the system building 
dialog, all peripheral devices and all communication devices 
associated with the ATD and TTY* line protocol handlers are 
designated as reccnnectable and will be automatically 
reconnected when power is restored. If any ADT or 
TTY*-assDciated device is not to be automatically reconnected, 
the Set Terminal Characteristics (STTY) directive associated 
with the device must not contain the -RECONNECT argument. 
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Power Resumption Functions 



The power resumption facility automatically performs tin 
following functions: 

• Restarts the device drivers, clock, communications 

subsystem, and display formatting and control facil 

• Reconnects all peripheral devices that were online i 
time of the failure. 

• Reconnects ATD- or TTY*-associated communication de^ 
that were online at the time of the failure, except 
those devices designated as not reconnectable. 

• Restores the screen forms on reconnected terminals 
controlled by the display formatting and control fat 

• Resets the system date and time If the date/time cl< 
separate battery backup unit. 

• Reloads the memory management unit. 

• Reestablishes the integrity of mounted volumes. 

• Restarts application tasks that were active when the 
failure occurred, provided the tasks used the disple 
formatting and control facility or contained user-wr 
code to handle power failure and power resumption. 

If an application task is to be notified when a power re 
has occurred, 1t must be written to check "rap 53 when t 
becomes active and is issuing its own instructions (not 
executing Executive instructions). (Refer to "Trap Hana 
Section 5.) 

After a power resumption has occurred, peripheral device 
reconnectable ATD- or TTY*-associated devices that were 
at the time of the failure are again brought online. Th 
operator may be required to initialize certain periphera 
devices. A terminal user may be required to reenter the 
line if he/she had not pressed the RETURN or XMIT key wh 
failure occurred. (Refer to the System User's Guide for 
details.) 
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The file recovery facility enables you to save record images 
from a file before it is updated and to later write these images 
back to the file, eliminating the alterations made during the 
updating. Every time a record is updated, a copy of the record, 
as 1t exists before the update, is written to a system-created 
file. The system-created file is called a recovery file; the 
records it contains are called before-images. 

The system uses recovery files to bring your data files to a 
consistent state following a software failure or a system 
failure such as that caused by a loss of power. When the 
before-images are applied in reverse chronological order to your 
data fT.es, the data files are rolled back to a previously 
established state. 



Ling Recoverable Files 

File recovery is optional. You designate a file as -ecoverable 
through the -RECOVER argument of the Create File corrmand. Files 
not created as recoverable can be made recoverable by 
specification of the -RECOVER argument of the Modify rile 
Attribute (MFA) command. Also, you can designate all files in a 
21 rectory or volume 'to be recoverable t-n rough the Modify 
Directory Attributes [MDA) cormiand. 

Recoverable files can be made nonrecoverable througn the 
Specification o r the -NORECOVER argument in the MFA or MDA 

commanc. 



y File Creation 



Each task group (or task, in some cases) having a data file 
designated as recoverable has associated with it a recovery 
file. The recovery file is created by the system wnen the first 
tefore-irnage for a recoverable file is about to be written. 

ATI recovery files are created subordinate to your working 
directory, unless you specif-ed otherwise by the Assign Recovery 
F'Me command. (The names of the files are recorded in the 
SSCATALOG directory, which is positioned under the root 
directory of the system volume. This directory 1s malntainec by 
the system,) Each recovery file is assigned a name of the form: 

SSREC.nnggtt 

where nn is the node identifier, gg is the group identifier, and 
tt is the task, ioentifier. 
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File Recovery Process 



The system recovers a data file (erases the updates madt 
by writing trie before-images back into the file. 

You declare points in your task group processing (calle< 
cleanpoints) at which all file updates are considered v< 
When a cleanpcint is declared, all before-images taken i 
that point are invalidated. New before-images are writ! 
you again begin to update the file. 

You car oerform a rollback at any time during processing 
a rollback is requested, the before images are written i 
file, wiping out updates made since the last cleanpoint. 

Use of the cleanpcint and rollback task group functions 
recommended in a transaction-oriented environment. 



Taking Cleanpoints 



When you consider the data in your task group's file(s) 
consistent and valid, declare a cleanpoint in your task 
Cleanpoints are established by SCLPKT macrocalls in Asse 
language programs and by the ZCLEAN utility in programs 
in higher-level languages (for example CALL "ZCLEAN" in 
When a cleanpoint is declared, the system performs the 1 
actions: 

• Writes all buffers modified by the task group to d1s 

• Updates all directory records for files modified by 
group. 

• Invalidates the recovery file before-images that haw 
taken for data files used by the task group. 

• Unlocks all previously locked records belonging to t 
group. (Tasks waiting for these records are activat 

The File System automatically performs a cleanpoint when 
recoverable file is closed. 
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Rollback initiates the recovery cf you.- task g-oup's files to 
the condition in which they were at the last cleanpoint. If 
arogramrcing in Assembly language, request a rollback by coding i 
SROLBK macrocall . If programming in a fvgner-level language, 
request a rollback by using the ZCROLL utility (fc r example, -in 
COBOL use a CALL "ZCROL^" statement). 

When you request a rollback, the system performs the following 
actions: 

• Takes before-images from the recovery file and writes their 
into the data files used by the task group, thereby wiping 
out upcates maae since the 'ast cleanpoint. 

• Invalidates the before-images for the task croup's data 
files on the recovery file. 

• Un'ocks all previously locked records oelonging to the task 
group. (Tasks waiting for these records are activated.) 

The -File System automatically performs a rollbac< when a task 
group terminates abnormally. 



After System Failure 

If recovery files exist, the operator should issue the Recove 
ccmmand sc that the system will perform a -olloack of all 
recoverable data files. 



TORAT10N 

File restoration provides the ability to preserve updates that 
have been mace to files, and to apply these upoates to saved 
versions of tne files if the original versions become 
corrupted. You cause images of records that have been modified 
(after-images) to oe recorded in a journal (after-image) file. 
You can then use the journal file in conjunction with the Save, 
Restore, and Roll Forward commands to restore files to a known 
state if cata in tne files is destroyed as a result of a device 
failure. (If I/O errors indicate any damaged files and/or 
volumes, file restoration proceoures are recommended). 
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Designating Restorabie Files 



You designate files as restorabie by specifying the -RE! 
argument of the Create File command- Files not created 
restorabie can be made restorabie by specifying the -RE! 
argument of the Modify File Attribute (MFA) command. A1 
can designate all files in a directory or volume to be 
restorabie through the Modify Directory Attributes (MOA; 
command. 

It is recommended that files designated as restorabie aT 
designated as recoverable (having the -RECOVER attribute 
provide for complete file integrity if a device or systc 
failure occurs. 

Restorabie files can be made nonrestorable by specifying 
-NORESTORE argument of the MFA or MDA command. 



Journal File Creation 



The journal file is created and maintained by the operat 
through the Open Journal, Close Journal, Display Journal 
Swap Journal commands. One system-wide journal file, on 
disk, records updates made to all restorabie disk files. 
system-created journal history file contains the name of 
current journal file and a History of all previous journ 
files, including the date and time they were created. 

Each t'Tie a record in a restorabie file is updated, the 
records on the journal file the image of the record as i 
after the modification (the after-image). The after-ima 
the updated record is written to the journal file at the 
the record in the file is physically updated. If the op 
specifies the -BEFORE argument in the Open Journal comma 
system will also record on the journal file the image of 
record as it exists before the modification (the before- 
You might want to record oefore-images for aud't purpose 

The journal file contains a running summary of all Chang 
to restorabie files (for example, if a restorabie file i 
renamed or modified, app r opriate entries are addeo to th 
journal file to reflect these changes). Restorabie disk 
cannot be modified in any way unless the journal file ha 
previously opened by the operator. 
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toration Process % 

For each file that is corrupted, the restoration process 
involves mcunting a known valid version of the file, 
reconstructed frorr data preserved during a previous save 
operation. The save operation involves preserving the aata 
contents and selected attributes of the uncorrupted file (by 
means of the Save command) before any catastrophe occurs, then 
restoring the file structures of the saved f<le (using the 
Restore command) after the file has been corrupted. Following 
these actions, you cause after-images from the journal file to 
be applied to the restorec file by. using the Roll Forward 
corrrrand. *he -estored filfi now ircorpc^a*:es the changes o r 
updates stored in the journal file since you last invoked the 
Save command. 

File restoration offers more extensive procedures if files are 
corrupted following a device failure and file recovery 
orocedures fail to return files to a consistent state. 

c or example, the operator opens the journal file and enters the 
Recover command. If the Recover command executes successfully, 
you can log in and continue processing. If the Recover command 
fails to execute successful ly, the operator must close the 
journal file, mount saved versions of ail files, and use the 
Restore command to reinstall the saved versions. The Roll 
Forward command is then entered. This command applies journal 
file images to all restored files, thereby updating the files to 
reflect modifications made after Save commands were entered for 
those files- File restoration is then complete and users can 
log in and continue processing. 



DINT RESTART 

The checkpoint restart facility allows you to provide a task 
group file recovery and program restart capability in an 
absentee processing environment. Through checkpoint restart, 
you can estaolish a point in your orogram to which you can 
return at any time and continue processing. This return point 
(caHed a checkpo*nt) is used to save the current status of the 
task group request. 

You can perform a restart to the most recently completed 
checkpoint after the abnormal termination of the task group 
request or at any point during the processing of tne task grouo 
request. A restart cannot be~performed from an earlier 
checkpoint, nor can it be performed after the normal termination 
of a task group request. 

Checkpoint restart does rot support tne use of the Listener 
secondary login facility. 
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Designating Restorabie Files 



Ycu designate files as restorabie by specifying the -RES 

argument of the Create File command. Files not created 

restorabie can be made restorabie by specifying the -RES 

argument of trie Modify File Attribute (MFA) corrmand. Al 
can designate all files in a directory or volume to be 

restorabie through the Modify Directory Attributes (MDA] 
corrmand. 

It 1s recommended that files designated as restorabie al 
designated as recoverable (having the -RECOVER attribute 
provide for complete file integrity if a device or syste 
failure occurs. 

Restorabie files can be made nonrestorable by specifying 
-NORESTORE argument of the MFA or MDA corrmand. 



Journal File Creation 



The journal file is createc and maintained by the operat 
through the Oper Journal. Close Journal, Display Journal 
Swap Journal commands. One system-wide journal file, on 
disk, records updates made to all restorabie disk files. 
system-created journal history file contains the name of 
current journal file* find a history of all previous jourr 
files, including the date and time they were created. 

Each time a record in a restorabie file is updated, the 
records on the journal file the image of the record as i 
after the modification (the after-image). The after-ima 
the updated record is written to the journal file at the 
the record in the file is physically updated. If the op 
specifies the -BEFORE argument in the Open Journal comma 
system will also record on the journal file the image of 
record as it exists before the modification (the before- 
You might want to record before-images for audit purpose 

The journal file contains a running summary o* all chang 
to restorabie files (for example, if a restorabie file i 
-enamed or modifiec, app r opriate entries are added to th 
journal file to reflect these changes). Restorabie disk 
cannot be modified in any way unless the journal file ha 
previously opened by the operator. 
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toration Process 

For each file that is corrupted, trie restoration process 
involves mounting a known valid version of the file, 
reconstructed from data preserved during a previous save 
operation. The save operation involves preserving the data 
contents and selected attributes of the uncorrupted file (by 
means of the Save command) before any catastrophe occurs, then 
restoring the file structures of the saved Pie (using tne 
Restore command) after the file has been corrupted. Following 
these actions, you cause after-images from the journal file to 
be applied to the restored file by. using the Roll Forward 
command, "he restored file now incorporates the changes or 
updates stored in the journal file since you last Invoked the 
Save coirmand. 

File restoration offers mere extensive procedures If files are 
corrupted following a device failure and file recovery 
procedures fail to return files to a consistent state. 

For example; the operator opens the journal file and enters the 
Recover command. If the Recover command executes successfully, 
you can log in and continue processing. If the Recover command 
fails to execute successfully, the operator must close the 
journal file, mount saved versions of all files, and use the 
Restore command to reinstall the saved versions. The Roll 
Forward command is then entered. This command applies journal 
file images to all restored files, thereby updating the files to 
reflect modifications made after Save commands were entered' for 
those files. File restoration is then complete and users can 
log in and continue processing. 

DINT RESTART 

The checkpoint restart facility allows you to provide a task 
group file recovery and program restart capability in an 
absentee processing environment. Through checkpoint restart, 
you can establish a point in your program to which you can 
return at any time and continue processing. This return point 
(called a checkpoint) is used to save the current status of the 
task group request. 

You can perform a restart to the most recently completed 
checkpoint after the abnormal termination of the task group 
request or at any point during the processing of the task group 
request. A restart cannot be performed from an earlier 
checkpoint, nor can it be performed after the normal termination 
of a task group request. 

Checkpoint restart does not support tne use of the Listener 
secondary login facility. 
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Checkpoint 



When a task requests a checkpoint, the system records t\ 
current contents of the task group's memory and the cun 
state of tasks, files, and screen forms onto a checkpoir 
you have previously assigned. The system then takes a 
cleanpoint for that task group so that recoverable file: 
synchronized with that checkpoint. (Refer to "File Rec< 
earlier in this section for a description of recoverable 
and cleanpoints.) 

The system supports one checkpoint task and any number c 
tasks that are dormant or waiting on requests placed age 
other tasks in the task group. (Thus, a single active c 
executing under the Command Processor and/or any number 
nested EC files can be checkpointed.) 



Checkpoint File Assignment 

You enable the checkpoint restart facility for your task 
and designate where its checkpoint images are to be recc 
issuing the Checkpoint File Assignment command- 
Checkpoints are written alternately into each of a pair 
checkpoint files. This technique ensures the availabili 
the previous valid checkpoint if e failure occurs during 
process of taking a checkpoint. The system locates and 
only the most recently completed successful checkpoint f 
pair o^ checkpoint files that you specified. 

Pathname When designating the checkpoint file, specify a single p 

(the last element of which can be a maximum of 10 charac 
The system appends the suffixes .1 and .2 as appropriate 
the system cannot find one or both of the specified chec 
files, it creates it (them). 
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Checkpoint ™ 

When a checkpoint is taken, the system writes a checkpoint image 
and performs a cleanpoint for all recoverable files being usee 
by the task group. If programming in Assembly language, recuest 
a checkpoint by cocing a JCKPT macrocall. If programming in a 
higher-level language, recuest a checkpoint through tne ZXCKPT 
utility (in COBOL you can use a CALL "ZXCKP*" statement or the 
RERUN clause in the I-0-COITROL paragraph;. 

it- Your task group must be in a state that allows the system to 
te take checkpoints. To be in a checkpointable state, tasks in tne 
group can have no outstanding reauests against tasks outside the 
group. Specifically, a task group is in a cneckpcintaole state 
when each task that Is part of the group has requested a 
checkpoint- is waiting on a request issued to another task in 
the task group, or is dormant (no current requests exist for the 
task). 

Once a checkpoint is recorded by a task group, it remain's 
available as a restart point until the next checkpoint request 
is completed, the current checkpoint file is disassigned (by the 
-0ISAS5IGN argument of tne Checkpoint File Assignment command), 
or the task group request is terminated normally. 



You can use the Defer Checkpoint macrocall to prevent or allow 
the taking of checkpoints by tasks within the task group. If 
you wanted to protect a procedure from being checkpointed, you 
would disable checkpoints at the beginning of the procedure and 
enable them at the end of the procedure. 

The lead task of the group may be waiting for both another task 
that is a member of the group and a "break" request. 
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Checkpoint Processing 



When a task group takes a valid checkpoint, the system i 
the following information on the current checkpoint fill 
established for that group: 

1. Executive information, including data structures, u: 
memory blocks obtained by Get Memory operations, da* 
segments of bound units linked with separate code ai 
nonshareable bound units, and floatable overlays. 

2. Status and pathnames of the standard I/O files. 

3. Memory locations and pathnames of shareable bound ui 

4. Current state of screen forms for terminals operatir 
the display formatting and control facility. 

5. Status and position of all active user files (files 
have been associated, reserved, or opened).. 

When your file information has been recorded, the checkf 
image is completed and a cleanpoint is taken. You must 
that files to be synchronized with the checkpoint restar 
process have been designated as recoverable. Since the 
System performs a cleanpoint when a recoverable file is 
you may have to take a checkpoint prior to closing the 1 
keep checkpoint restart synchronized with the state of 1 
recoverable file. (Temporary files cannot be cesignatec 
recoverable.) 

Checkpoints cannot be taken while an active local mail n 
group exists. In other words, a checkpoint cannot be ts 
the period between message initiation or acceptance and 
termination; refer to "Message Facility Macrocall Interf 
Section 5. 

Checkpoints are not made automatically obsolete by the n 
termination of the task under which they were issued. T 
invalidate a previous checkpoint (taken during the execu 
one command) before processing a new command, you must t 
checkpoint immediately prior to the termination of that 
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You can perform a restart at tne following times: 

• During the processing of the task group request that issued 
the checkpoint recuest. 

• During the processing of a task group request scheduled 
after the abnormal termination of the task group request in 
which the checkpoint was taken. 

• When the system is reinitialized following a system failure. 

When a restart request is issued, the task group issuing the 
request is terminated abnormally and the task group request 
recorded on the checkpoint file is again put into effect. 

The system locates the most recently completed checkpoint and 
reads the checkpoint image from the file, rebuilding the 
Executive data structures and memory blocks, reloading bound' 
units, and repositioning active user files. 

P r ocedura 7 coae and worxsoace must occupy the same physical 

memory locations that were used when the checkpoint was taken. 

In genera" , task groups that are to be restarted must be the 

sole users of memory pools. Shareable bound units referred to 4 

by these groups must be permanently loaded (through the Load ™ 

command in the system startup EC file). The configuration under 

which the restart is performed must be identical to that which 

existec when the checkpoint was taken. 
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To restart from the last completed checkpoint (and to al 
current task group request, if restarting during the se: 
issue the Restart command. The operator can restart an 
task group that has a valid checkpoint by using the -GR< 
argument of the Restart command. If the memory blocks i 
to effect the restart are not available, the restart 1s 
aborted. Specification of the -WTMEM argument of the R< 
command causes the system to wait until the specific met 
blocks required to perform the restart become available 

If this is a restart following a system failure, the Re< 
command must have been issued by the operator, or throuc 
file, to perform a system-wide rollback of all recoveral 
files. 

If a restart is performed during a session, the abort 
(termination) of the group request causes a rollback of 
recoverable files in your task group. The abnormal terr 
of the group request causes the last completed checkpoli 
to be retained as a valid checkpoint. The Abort Group < 
Group Request cownands force an abnormal termination; tl 
command causes a normal termination. (The normal termii 
the Command Processor with a nonzero value in the $R2 n 
is treated as an abnormal termination for checkpoint Ml 
purposes.) 

The Validate Checkpoint command or active function can t 
to ascertain whether the specified checkpoint file pair 
a valid restartable checkpoint. 
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When you 'ssue the Restart command, the system per-'oms the 
fc" "owing steos: 

1. Locates the most recently completed checkpo-rt. 

2. Validates that the restart is being performec under the sane 
user id as that used when the cneckpoi r t was take".. 

3. Rebuilds Executive data structures. 

4. Reads nonshareable bound units, data segments, flcatable 
overlays, anc memory blocks that were obtained by get-merrory 
openations from the checkpoint image into the same memory 
locations they occupied at the time the checkpoint was 
taken. 

5. Reloads shareable bound units in the system memony pool . 
Only the code segment is reloaded if the bcunc unit was 
linked witn sepanate code and oata. Unless it was linked 
with the restart relocatable attribute (L'nker RR 
directive), the code segment is reloaded at the sane system 
pool memory locations occupied when the checkpoint was 
taken. 

6. Assoc ; ates, gets, opens, and positions active user files 
rscordec on the checkpoint image. Rollbacc should have been 
performec alreacy (refer to "Requesting a Restart" anove). 

7. Restores the screen content cf terminals that were operating 
under the disolay formatting and control facility and were 
active at the time of the checkpoint. 

8. Reissues the break request if such a request had been issued 
Dy the lead task at the time of the checkpoint. 

9. Turns on the task that issued the checkpoint request at tne 
next sequentia' instruction after the checkpoint. 

The checkoointed state of the standard I/O files (user-in, 
user-out, counand-in, and error-out) is reestablished at restart 
time. Modifications made to files (for examp'e, EC files) 
between tne checkpoint and the restant must be restricted to 
those that do not invalidate the reoos J tioning cf the files. A 
command being restarted must remain in the same position *r the 
file; only those commands that follow the restarted commanc have 
any effect on the restarted task group neouest. 
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Shareable bound units being used by a cneckpointed task 
are reloaded and not restored from a checkpointed memor 
(except for the data segments of bound units linked witi 
separate code and data). Thus, all such bound units shi 
contain only code. All shareable bound units in use by 
restarting task group must be identical to the versions 
existed at the checkpoint. They cannot be relinked- I 
Overlay Area Table (OAT) is in use for such a bound unl' 
overlay area can be reserved at the time the checkpoint 
taken. 

If you have application programs that issue physical I/I 
for communication devices, you must reissue connects to 
devices before issuing Reac and Write orders to them. 



CZ03-02 



